Closes #1037

Motivation and Context

AuthorizationManager::discover_metadata() falls back to the legacy default endpoints, /authorize, /token, and /register, based on the base URL when discovery returns nothing. This fallback is required for the auth/2025-03-26-oauth-endpoint-fallback conformance scenario. However, it makes a successful fallback look the same as metadata that the server actually published. As a result, callers cannot tell whether OAuth metadata was discovered or synthesized for compatibility. That behavior was originally introduced in #507 and changed by #960.

This changes AuthorizationManager::discover_metadata() itself to return DiscoveredAuthorizationMetadata, which contains both the AuthorizationMetadata and its AuthorizationMetadataSource. The source distinguishes protected resource metadata, authorization server metadata, and the legacy endpoint fallback; is_discovered() reports whether the server published metadata.

Because v3 is still in beta, this makes provenance part of the primary discovery contract now instead of adding a parallel method that would need to be retained long-term. Internal SDK and conformance call sites explicitly extract .metadata; the discovery order, legacy endpoint synthesis, and conformance behavior remain unchanged.

How Has This Been Tested?

Unit tests cover all three sources

Breaking Changes

AuthorizationManager::discover_metadata() now returns Result<DiscoveredAuthorizationMetadata, AuthError> instead of Result<AuthorizationMetadata, AuthError>.

Callers that need the metadata directly must extract the metadata field:

// Before
let metadata = manager.discover_metadata().await?;
manager.set_metadata(metadata);

// After
let discovered = manager.discover_metadata().await?;
manager.set_metadata(discovered.metadata);

Callers can inspect discovered.source or call discovered.source.is_discovered() before consuming the metadata.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed